In the JSON editor ie. the middle one of the three in the Documents tab. Suppose you have this document:

{
  a: Double(1)
  b: Long(1)
  object: {
    c: Double(1)
    d: Long(1)
  }
}

and you edit it in the JSON editor, it gets serialised as

{
  "a": 1,
  "b": 1,
  "object": {
    "c": 1,
    "d": 1
  }
}

so when you save that back it becomes

{
  a: Int32(1)
  b: Int32(1)
  object: {
    c: Int32(1)
    d: Int32(1)
  }
}

ie. we implicitly change the type of the Double or Long into an Int32 because 1 can safely be represented by a 32bit int.

This change will check the type of a property and if it is now Int32 and it was Double or Long, it will turn it back into a Double or Long when you save. So the document keeps its original "unnecessary" type.

Just to be clear: This only applies to the json editor. The other editors are unaffected.

In case you're wondering why this is broken in the json editor but not in the document editor:

The reason why we lose the type information is because it isn't encoded in the JSON and then we do HadronDocument.FromEJSON(value || '') which just re-infers all the types using TypeChecker.type(). TypeChecker.type() will use _bsontype if it is set, otherwise it does this thing where it tries to figure out if it should be a double or an int.

Because it uses _bsontype if set and because the double and Int64 editors explicitly cast the type, the exact type is never lost in the document editor.

I decided to recurse on objects, but leave arrays alone. It is really tricky and error-prone to detect if the user's intention was to have the whole array use Long and Double and never Int32 or not. Although it would have potentially been useful for embeddings / vectors where the values just might end up as a round number in an array that is otherwise doubles. I tried a few things but gave up on that idea every time because it just felt inherently dangerous. We could re-visit the idea in the future if necessary. Follow-up ticket: https://jira.mongodb.org/browse/COMPASS-9578